Many products developed in the preceding decades have been designed to function using a mixture of computer hardware and software. When such a product is not intended to be perceived as a computing platform, it is often referred to as an embedded computing system, or embedded system. Examples include DVD players, microwave ovens, digital cameras, cell phones, automobile engine controllers. These systems contain a computing element such as a microprocessor or microcontroller and specific software to perform their intended function, which is typically referred to as “firmware” because of the high level of hardware dependence and lack of portability.
Some embedded systems have been designed to allow their firmware to be altered after leaving the factory. This alteration could be to add new features to the product (i.e., an “upgrade”), a change to alter the operation of the device to customize it for a specific application, or to fix defects in the product discovered after the product has been shipped. Typically, these changes are done disruptively, i.e., the system is shut down, the firmware changed, and then the system is reinitialized or restarted. The system is unavailable during the time that the firmware is being changed, and programmable settings may have to be restored.
The disruption may be acceptable in many cases, but some embedded products are designed to be in use continuously, i.e., 24 hours a day. Examples include a system that controls the traffic lights at a busy intersection, a radar controller at a busy airport, a communications adapter in a computer system used for worldwide credit card transactions, telephone controls in an emergency response (911) call center. A specific product with this requirement is the input/output (IO) adapter cards in an IBM e-server Z990 computer system. In these high availability systems, there is no convenient time when the system can be shut down for several minutes while the firmware is changed.
In such high availability systems, the capability to concurrently (i.e., non-disruptively) change the operating firmware would be desirable. This capability is referred to herein as “concurrent firmware activation” or “non-disruptive code load”. To be considered non-disruptive, the change to the firmware should have negligible impact on the intended function of the system; that is, no errors created, no loss of computing resources, no data corruption, minimal performance degradation. The impact to the end users is typically a lack of response or function for a very short period of time, followed by normal operation with the new firmware. The acceptable length of time for the change may range from milliseconds to seconds. The exact specification is dependent on the application.
In some embedded systems, the firmware is implemented as several object modules that are dynamically linked together at initialization time. The linking is accomplished by a linker resident in the first module to be loaded into memory at initialization time. In other systems, the firmware is implemented as a single statically linked module. The linking was done using a different computing platform, and only the final single executable module is loaded into the embedded system memory.
In some systems, non-disruptive code load can be accomplished by the resident linker dynamically linking in a new module with previously loaded modules, or in place of a previously loaded module. The loader and linker may be part of an embedded operating system, and most of the operating system typically can not be concurrently altered. There are a number of reasons why this can not be done, but one is that the module containing the loader would be overwriting itself.
When using a multiple module system, even if the loader/linker module is not being replaced, incompatibilities between old and new modules may arise, making the technique more difficult, if not impossible. When replacing more than one module, there are multiple steps and states involved, increasing potential operational problems. In some embedded systems, memory may be constrained, leaving no room for new modules while an old module is still present. A solution would be to consolidate the modules into one large statically linked module, but the problem of the loader/linker overlaying itself prevents this. The present invention is directed to solving this problem.